Durante dos anios la conversacion sobre como integrar agentes LLM en producto se redujo a una sola respuesta: un chat con historial a la izquierda, mensaje abajo y area de burbujas en el medio. Esa era la forma canonica, la plantilla de facto, y todo producto nuevo la reusaba. Doce meses despues de que la conversacion industrial empezara a cuestionar ese consenso, aparecen patrones de UI pensados especificamente para lo que hacen los agentes hoy. Algunos estan consolidandose con rapidez. Otros son moda del ciclo de 2025 que no sobrevivira a una evaluacion honesta.
Este post repasa los principios que empiezo a ver funcionar en producto real, los que siguen siendo experimentos, y donde creo que se va a estabilizar la interfaz de agente en los proximos meses.
Por que el chat dejo de ser suficiente
El chat funcionaba mientras el agente hacia una tarea por vez y la conversacion cabia en una pantalla. En cuanto los agentes empezaron a hacer trabajo de fondo durante minutos, invocar varias herramientas en paralelo y mantener estado sobre archivos, el chat se quedo corto. La ventana de conversacion empezo a llenarse de ruido, los mensajes de herramienta se mezclaban con los mensajes del modelo, y el usuario perdia la vision de lo que estaba pasando realmente.
Los sintomas concretos que vi repetirse en muchos productos eran tres. El primero era que el usuario pulsaba el boton de detener porque no sabia si el agente seguia trabajando o se habia quedado colgado. El segundo era que, despues de una ejecucion larga, el usuario no sabia que archivos habian cambiado ni que comandos se habian ejecutado. El tercero era que, cuando el agente fallaba, el usuario no tenia forma clara de ver en que paso fallo ni como reanudar.
Esos tres sintomas apuntaban al mismo problema: el chat como metafora no era adecuado para tareas con estado, ejecucion larga y herramientas. Hacia falta algo distinto.
El patron del panel de progreso
El primer patron que he visto funcionar bien es separar la conversacion del progreso de la tarea. La conversacion se queda en una columna, y el progreso se muestra en un panel separado que lista paso a paso lo que el agente esta haciendo, con estados de cada herramienta, archivos tocados, comandos ejecutados y salidas resumidas. El usuario ve la historia de la ejecucion sin tener que leer la conversacion completa.
Este patron ha aparecido casi identico en varios productos recientes. Claude Code, Cursor, Cline y Aider tienen variantes del mismo principio: conversacion minima, panel de progreso rico. La convergencia sugiere que el patron funciona, no es casualidad.
La clave del panel de progreso es que cada paso sea colapsable y auditable. El usuario no quiere leer cada salida intermedia, pero si quiere poder abrir un paso concreto y verlo cuando algo ha ido mal. Es la diferencia entre una barra de progreso simple y un registro navegable.
La interfaz de revision y aprobacion
El segundo patron consolidado es la interfaz de revision. Cuando un agente esta a punto de ejecutar una accion con efectos laterales, como modificar archivos, ejecutar un comando o enviar una peticion a una API, el usuario debe poder revisar y aprobar antes de que ocurra. En teoria esto ya estaba en el chat original como confirmacion de texto, pero en la practica la confirmacion textual es insuficiente porque el usuario no lee el mensaje completo.
Lo que funciona mejor es mostrar el cambio exacto propuesto con la semantica visual del dominio: un diff lado a lado si son archivos, una tabla si son filas de base de datos, una vista previa renderizada si es contenido publicable. La aprobacion deja de ser un boton ciego y se convierte en una decision informada.
Este patron requiere que el agente exprese su intencion en un formato revisable antes de actuar. Es una presion arquitectonica util: obliga a separar el razonamiento del efecto, lo que hace el sistema mas seguro y mas depurable.
El explorador de ejecuciones
El tercer patron, menos consolidado pero prometedor, es el explorador de ejecuciones. Un agente que opera durante horas puede haber ejecutado decenas de tareas, y el usuario necesita navegar ese historial con un modelo mental claro. No sirve una lista lineal; hace falta una vista arborescente donde cada tarea tiene subtareas y cada invocacion tiene entradas y salidas.
Los productos que empiezan a implementar este patron, como OpenAI Agent Responses o las vistas de ejecucion en plataformas como Modal, experimentan con estructuras jerarquicas. No hay consenso todavia, pero la direccion esta clara: el registro lineal no escala con la complejidad actual.
Moda que no funciona
Hay patrones que han aparecido con mucho ruido pero no han cuajado. El primero es la interfaz de voz como canal principal para agentes de trabajo. Sirve para asistentes de consumo y casos de manos ocupadas, pero no para tareas tecnicas donde el usuario necesita ver codigo, diffs y tablas.
El segundo es la interfaz cero, el agente que aprende tus habitos y actua sin confirmar. Suena ambicioso pero choca con la realidad de que los modelos siguen equivocandose con suficiente frecuencia como para que el usuario necesite control sobre acciones con efecto. Una fantasia para tareas importantes.
El tercero es el agente antropomorfizado con avatar y mimica facial. Genera interes en demos pero ruido en uso habitual. Los equipos que lo han probado en producto han acabado quitandolo porque distrae.
Principios que empiezan a emerger
Cinco principios se repiten en los productos que funcionan. El primero es hacer visible el estado del agente en todo momento. El usuario nunca debe dudar si esta trabajando, esperando entrada o ha terminado. La ambiguedad de estado es el problema numero uno.
El segundo es separar conversacion de ejecucion. Hablar con el agente y ver lo que hace son dos tareas distintas que requieren dos espacios visuales distintos.
El tercero es preservar la reversibilidad. Todo paso de efecto lateral debe ser revertible o al menos auditar el cambio con suficiente detalle para deshacerlo. El usuario debe poder recuperar el estado previo si decide que la direccion era incorrecta.
El cuarto es calibrar la confianza explicitamente. El agente debe indicar cuando esta haciendo algo rutinario y cuando algo experimental donde el usuario deberia revisar con mas atencion.
El quinto es dejar al usuario el vocabulario del dominio. Si el dominio es codigo, la UI debe hablar de archivos, funciones y commits. Si es soporte, de tickets y conversaciones con el cliente. Una UI generica de chat en un dominio tecnico pierde capacidad expresiva.
Como pensar la decision
Cuando un equipo me pregunta como disenar la UI de su producto de agente, la pregunta que mas ayuda no es que patron copiar sino que tareas estan haciendo los usuarios y cuanto dura cada una. Si la tarea dura menos de un minuto y no tiene efectos persistentes, el chat es suficiente. Si dura mas de cinco minutos o tiene efectos persistentes, el chat deja de bastar y hay que pensar en panel de progreso, revision y explorador de ejecuciones.
La otra pregunta util es cuanta confianza tiene el usuario en el agente. Si es nueva, hay que sobreinformar: cada paso visible, cada decision auditable, cada accion reversible. Si el usuario lleva meses usandolo y confia, se puede simplificar y ocultar detalles. El mismo producto probablemente necesita dos modos de UI para la misma funcionalidad segun el nivel de madurez del usuario.
Mi conviccion despues de ver este ciclo es que el chat va a quedarse como canal de entrada universal, pero los productos serios van a tener interfaces mucho mas ricas detras. La era de la burbuja de texto como unica metafora para agentes esta terminando, y los equipos que inviertan ahora en patrones alternativos van a tener ventaja competitiva cuando la expectativa del usuario evolucione en los proximos meses.
